User-Centred Requirements Handbook |
This process specifies the system functions that each user will require for the different tasks that they perform. The most critical task functions are identified so that more time can be paid to them during usability testing later in the design process. The form below (Form 4) shows the structure for a functionality matrix. It is important that input from different user groups is obtained in order to complete the matrix fully.
Typical Application Areas
This method is useful for systems where the number of possible functions is high (e.g. in a generic software package) and where the range of tasks that the user will perform is well specified. In these situations, the functionality matrix can be used to trade-off different functions, or to add and remove functions depending on their value for supporting specific tasks. It is also useful for multi-user systems to ensure that the tasks of each user type are supported.
System: |
Functionality Matrix | |||||
| Functions | ||||||
| Users and Tasks | F1 | F2 | F3 | F4 | F5 | Key:
 = Critical to task
 = Occasional use |
| User A | Comments
|
|||||
| Task A | |
|||||
| Task B | |
|||||
| Task C | |
|||||
| User B | ||||||
| Task A | |
|||||
| Task B | |
|||||
| Task C | |
|||||
| Function selection | ||||||
Figure 11. Structure for Functionality matrix
Benefits
• It can be tailored to suit varying design processes and in-house styles.
• It allows different user types to be considered together in a single process.
• Superfluous functions are identified.
• It represents a reference in subsequent product lifecycle stages and may be updated in the light of prototyping.
Limitations
• The prime focus is on functions and features rather than interface appearance.
• It can be cumbersome for large numbers of functions.
What you need
Resources required fairly small. Requires input from different user types to complete matrix fully.
Process
1. Identify user groups (or take from Form 3) and enter into matrix rows.
2. Identify tasks per user group and enter into matrix rows.
3. List potential functions and features and enter into matrix columns.
4. Identify functions which are critical to task.
5. Identify functions which are only occasional used.
6. Add new functions or features as required to support gaps in tasks.
7. Remove functions which are not required.
8. Develop prototypes to help create more detailed user requirements specification.
Practical guidelines
• Start off with a simple high level version of the matrix, to get an overview of the main tasks and related groups of functions. This will help to define the scope of the matrix and help to keep it within manageable proportions.
• Use a spreadsheet package to manage large functionality matrices. A print out from this spreadsheet can then be used for group discussion.
Further information
Catterall (1990).